Dynomotion

Group: DynoMotion Message: 14607 From: geast1967 Date: 4/18/2017
Subject: Gcode viewer KMotionCNC colors
Hello.
I want to change in KMotionCNC the way that in the Gcode viewer screen the part for cutting is shown.
Now you press the "simulate" button and the part is drawn at the screen with green color and the rapid movements with red. After the green "Start" button is pressed the drawed part is erased and starts to drawed again in real time the actual path the tool is doing.
I want to change it in the way, that when you press the "Start" button the part should not be erased and the actual cutted path be shown with different color like white, on the drawed part.
I was able to make some changes in the KMotionCNC program, by manipulating the command "m_ColorFeed.Set(0,255,0,128);"
The problem is that the color is changing, but it is not shown on the screen. The time the tool is passing on the previous drawed path with white color it is still shown green. I also try with different values at alpha parameter in the ColorFeed.Set() function but it seems not to be changing anything.It suppose to change the transparency of the color. Can anyone suggest another approach to the issue? 
Regards.


Group: DynoMotion Message: 14608 From: Tom Kerekes Date: 4/19/2017
Subject: Re: Gcode viewer KMotionCNC colors

I don't think you can really "draw over" lines in OpenGL.  All the lines are placed together in 3D space and then rendered.  I found this Thread for example:

http://stackoverflow.com/questions/7836208/how-to-correctly-render-coincident-polygons-in-opengl-es

The alpha is an interesting idea but I'm not sure how OpenGL handles alpha with pure lines.

The Path3D object that KMotionCNC uses to draw the line paths ignores any alpha color setting.  I think you would have to make changes a few places to support it such as changing:

                ::glColor3ub(pNew->GetColor()->r(),pNew->GetColor()->g(),pNew->GetColor()->b());

to

                ::glColor4ub(pNew->GetColor()->r(),pNew->GetColor()->g(),pNew->GetColor()->b(), pNew->GetColor()->a());
Regards
TK

On 4/18/2017 11:32 PM, g.astras@... [DynoMotion] wrote:
 

Hello.
I want to change in KMotionCNC the way that in the Gcode viewer screen the part for cutting is shown.
Now you press the "simulate" button and the part is drawn at the screen with green color and the rapid movements with red. After the green "Start" button is pressed the drawed part is erased and starts to drawed again in real time the actual path the tool is doing.
I want to change it in the way, that when you press the "Start" button the part should not be erased and the actual cutted path be shown with different color like white, on the drawed part.
I was able to make some changes in the KMotionCNC program, by manipulating the command "m_ColorFeed.Set(0,255,0,128);"
The problem is that the color is changing, but it is not shown on the screen. The time the tool is passing on the previous drawed path with white color it is still shown green. I also try with different values at alpha parameter in the ColorFeed.Set() function but it seems not to be changing anything.It suppose to change the transparency of the color. Can anyone suggest another approach to the issue? 
Regards.



Group: DynoMotion Message: 14612 From: Hardy Family Date: 4/19/2017
Subject: Re: Gcode viewer KMotionCNC colors
I have not used OpenGL-ES, but 'desktop' GL supports alpha (and even lighting) for lines.  Lines also use the depth buffer.  If you draw a line *exactly* over another one, then the second drawing will display provided that your depth buffer comparison is set to "less or equal" (in Z depth) instead of the usual "less than".

We have done our own implementation using Open Scenegraph (OSG), which is a wrapper around the raw OpenGL API, but it saves a lot of work.  The approach for drawing the tool path in different colors is to have one big line strip buffer, which is initially filled with the simulator results.  You probably want to use a color index with each coordinate to distinguish rapids from feeds etc.  Then, it is a matter of manipulating the color index and redrawing as the actual tool path progresses.  All the color indices for the 'done' part of the tool path are updated to index a brighter color etc.  You don't need to worry about the depth buffer.

We found a few challenges doing it this way: firstly, the actual coordinates coming in might be subtly different than the simulated results (rounding error etc.) so you need a bit of slack when comparing incoming coordinates to the simulated points in the line strip buffer.  Eventually, the coordinates may be way off (e.g. the user jogged and changed offsets) so you then need to start using a new line strip and ignore the simulated line strip.

Second, using color indices is inefficient, since it is harder to optimize for the graphics hardware acceleration.  This is noticeable when displaying millions of line segments.  So the approach we took was to have a line strip for each change of color, with each line strip taking the 'fast path' because it uses a single color.  This works out OK, since the vast majority are usually feeds, with only a few rapids interspersed throughout.  Use one big contiguous buffer for all points, and use the appropriate indices when calling the OpenGL line strip functions.  There's a bit of book-keeping trickiness required for the change from 'simulated' to 'done', but if you can handle the color indexing then this should be obvious.


Regards,
SJH


On Wed, Apr 19, 2017 at 4:10 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

I don't think you can really "draw over" lines in OpenGL.  All the lines are placed together in 3D space and then rendered.  I found this Thread for example:

http://stackoverflow.com/ questions/7836208/how-to- correctly-render-coincident- polygons-in-opengl-es

The alpha is an interesting idea but I'm not sure how OpenGL handles alpha with pure lines.

The Path3D object that KMotionCNC uses to draw the line paths ignores any alpha color setting.  I think you would have to make changes a few places to support it such as changing:

                ::glColor3ub(pNew->GetColor()- >r(),pNew->GetColor()->g(), pNew->GetColor()->b());

to

                ::glColor4ub(pNew->GetColor()- >r(),pNew->GetColor()->g(), pNew->GetColor()->b(), pNew->GetColor()->a());
Regards
TK

On 4/18/2017 11:32 PM, g.astras@... [DynoMotion] wrote:
 

Hello.
I want to change in KMotionCNC the way that in the Gcode viewer screen the part for cutting is shown.
Now you press the "simulate" button and the part is drawn at the screen with green color and the rapid movements with red. After the green "Start" button is pressed the drawed part is erased and starts to drawed again in real time the actual path the tool is doing.
I want to change it in the way, that when you press the "Start" button the part should not be erased and the actual cutted path be shown with different color like white, on the drawed part.
I was able to make some changes in the KMotionCNC program, by manipulating the command "m_ColorFeed.Set(0,255,0,128); "
The problem is that the color is changing, but it is not shown on the screen. The time the tool is passing on the previous drawed path with white color it is still shown green. I also try with different values at alpha parameter in the ColorFeed.Set() function but it seems not to be changing anything.It suppose to change the transparency of the color. Can anyone suggest another approach to the issue? 
Regards.




Group: DynoMotion Message: 14613 From: geast1967 Date: 4/20/2017
Subject: Re: Gcode viewer KMotionCNC colors
Thanks Tom, i try that and now the Path3D object supports alpha, but it has no effect on the second line which is drawn over the dimmed first line.
I don't know how can i implement the suggestion of Hardy Family
" If you draw a line *exactly* over another one, then the second drawing will display provided that your depth buffer comparison is set to "less or equal" (in Z depth) instead of the usual "less than"."
Perhaps this will do the job...
Group: DynoMotion Message: 14614 From: geast1967 Date: 4/20/2017
Subject: Re: Gcode viewer KMotionCNC colors
Attachments :
This is now how it looks, but only if you rotate the part.
  @@attachment@@
Group: DynoMotion Message: 14615 From: geast1967 Date: 4/20/2017
Subject: Re: Gcode viewer KMotionCNC colors
Another idea, if we could draw a thicker line, perhaps it will be shown on top of the previous one.
Group: DynoMotion Message: 14616 From: Hardy Family Date: 4/20/2017
Subject: Re: Gcode viewer KMotionCNC colors
To modify depth buffer comparisons, code

glDepthFunc(GL_LEQUAL);

The default is GL_LESS.  If you are drawing pixel-wide lines and don't care too much about overlapping, you could also turn off depth testing altogether with GL_ALWAYS.  We have found that the best visual results are obtained by having non-overlapping line strips, one for the 'done' tool path and the other for the remainder of the simulation.  Draw the done path first and use normal depth buffer testing.

Regards,
SJH


On Thu, Apr 20, 2017 at 7:03 AM, g.astras@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Another idea, if we could draw a thicker line, perhaps it will be shown on top of the previous one.


Group: DynoMotion Message: 14619 From: Tom Kerekes Date: 4/20/2017
Subject: Re: Gcode viewer KMotionCNC colors

One thing that may help with removing the "Done Path" is that all the points in the path maintain a "sequence number".  This is an increasing number that is related all the way back to the GCode that created it.  For GCode that starts at the beginning and without subroutines it is the simply the GCode line number.   So for example when running the job and adding new path points with a certain sequence number you might remember the sequence number and then when the display list is regenerated not draw lines in the pre-view section with a sequence number less than or equal to that sequence number.

Regards

TK


On 4/20/2017 8:22 AM, Hardy Family hardy.woodland.cypress@... [DynoMotion] wrote:
 
To modify depth buffer comparisons, code

glDepthFunc(GL_LEQUAL);

The default is GL_LESS.  If you are drawing pixel-wide lines and don't care too much about overlapping, you could also turn off depth testing altogether with GL_ALWAYS.  We have found that the best visual results are obtained by having non-overlapping line strips, one for the 'done' tool path and the other for the remainder of the simulation.  Draw the done path first and use normal depth buffer testing.

Regards,
SJH


On Thu, Apr 20, 2017 at 7:03 AM, g.astras@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Another idea, if we could draw a thicker line, perhaps it will be shown on top of the previous one.



Group: DynoMotion Message: 14624 From: geast1967 Date: 4/21/2017
Subject: Re: Gcode viewer KMotionCNC colors
Well i code this
"
To modify depth buffer comparisons, code

glDepthFunc(GL_LEQUAL);
"
but had no visual effect.

To that what Tom suggest, i try to execute the code with a little difference from the simulated path, by moving a little the machine in X and Y by 1 mm and the zero and execute. The path was drawn shifted by 1 mm in both axis and was very good show highlighted.
So my idea is if i could draw the simulated path not where it should, but shifted a little.Where is actually the function, where it defines at what coordinates the simulation starts to be drawn?   
Group: DynoMotion Message: 14625 From: TKSOFT Date: 4/21/2017
Subject: Re: Gcode viewer KMotionCNC colors
This line of code in KMotionCNCDlg.cpp is what adds in the lines. You
might add an offset here. I would think a small offset in Z might work
better. A shift in XY would still overlay segments on diagonal lines.
Although a shift in Z might be bad if viewed from behind. Units should
be inches.

p->ActualGViewParent->m_Path->AddVertexTool(new
CVertex3dFast(x,y,z,p->m_ColorFeed,sequence_number,ID));

Regards
TK


On 2017-04-21 08:25, g.astras@... [DynoMotion] wrote:
> Well i code this
> "
> To modify depth buffer comparisons, code
>
> glDepthFunc(GL_LEQUAL);
> "
> but had no visual effect.
>
> To that what Tom suggest, i try to execute the code with a little
> difference from the simulated path, by moving a little the machine in
> X and Y by 1 mm and the zero and execute. The path was drawn shifted
> by 1 mm in both axis and was very good show highlighted.
> So my idea is if i could draw the simulated path not where it should,
> but shifted a little.Where is actually the function, where it defines
> at what coordinates the simulation starts to be drawn?
>
>
> Links:
> ------
> [1]
> https://groups.yahoo.com/neo/groups/DynoMotion/conversations/messages/14624;_ylc=X3oDMTJyb3JybW1jBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMxNDYyNARzZWMDZnRyBHNsawNycGx5BHN0aW1lAzE0OTI3ODgzMzA-?act=reply&messageNum=14624
> [2]
> https://groups.yahoo.com/neo/groups/DynoMotion/conversations/newtopic;_ylc=X3oDMTJmNmMxbzk3BF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0OTI3ODgzMzA-
> [3]
> https://groups.yahoo.com/neo/groups/DynoMotion/conversations/topics/14607;_ylc=X3oDMTM3bDgyYzBoBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRtc2dJZAMxNDYyNARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzE0OTI3ODgzMzAEdHBjSWQDMTQ2MDc-
> [4]
> https://groups.yahoo.com/neo/groups/DynoMotion/photos/photomatic/1088940799;_ylc=X3oDMTE4M3R1OW82BF9TAzk3MzU5NzE0BGNmOQNQSE9UT01BVElDBHNlYwNtZWdhcGhvbmU-
> [5] https://yho.com/1wwmgg
> [6]
> https://groups.yahoo.com/neo/groups/DynoMotion/info;_ylc=X3oDMTJmbjU3bDNmBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0OTI3ODgzMzA-
> [7]
> https://groups.yahoo.com/neo/groups/DynoMotion/members/all;_ylc=X3oDMTJnYjljOWpqBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxNDkyNzg4MzMw
> [8]
> https://groups.yahoo.com/neo/groups/DynoMotion/photos/photostream;_ylc=X3oDMTJnMXYzdTYzBF9TAzk3MzU5NzE0BGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDdnRsBHNsawN2cGhvdARzdGltZQMxNDkyNzg4MzMw
> [9]
> https://groups.yahoo.com/neo;_ylc=X3oDMTJldXVwZ2sxBF9TAzk3NDc2NTkwBGdycElkAzE1ODU4MDAxBGdycHNwSWQDMTcwNjU1NDIwNQRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQ5Mjc4ODMzMA--
> [10] https://info.yahoo.com/privacy/us/yahoo/groups/details.html
> [11] https://info.yahoo.com/legal/us/yahoo/utos/terms/
Group: DynoMotion Message: 14626 From: geast1967 Date: 4/22/2017
Subject: Re: Gcode viewer KMotionCNC colors
Attachments :
Yes thanks Tom, this did the job. I had to use a shift of 0.07 to be visible.

"p->ActualGViewParent->m_Path->AddVertexTool(new CVertex3dFast(x+0.07,y+0.07,z,p->m_ColorFeed,sequence_number,ID));"

Here is how it looks with the green alpha set to 100 and the white set to alpha 255.
m_ColorFeed.Set(0, 255, 0, 100);        // Green dimmed
m_ColorFeed.Set(255, 255, 255, 255);    // White highlighted
  @@attachment@@